package md.specialEqp.inspect;
//先有旧的数据，才再去搞的enum定义，数据库DB存储用Byte 1个字节/数字

import com.fasterxml.jackson.annotation.JsonCreator;

import java.util.Arrays;

/**任务状态, 作业可能的阶段： Task统计显示需求。
新生成未定部门，部门分配，科室分配，责任人派工，已派工，等待复检，等待整改反馈，已完成，作废；
 组织架构： 企业- 部门- 科室 -负责人（单一责任人）。
 检验报告不合格的可能安排一次机会复检 重新派工。
 特例情况！一直就完成不不了的任务，Isp就无法终结？Isp终结了，才能回头把Task=已完成。
 8个可能状态：等待部门分配 等待科室分配，等待责任人派工， 已派工好了检验去， 等待复检 等待整改反馈，任务已完成  作废任务；
 */

public enum TaskState_Enum {
    /**新生成的，未定部门，有的业务不好立刻就确认归属部门。部门不一定已经确定？
     * 假如部门未指定的，【针对本阶段任务】安排:批作业功能+后台任务去可直接指定默认的部门。
     * INIT =0
     * */
    INIT,
    /**部门已经指定, 部门内分配,科室还未指定的*/
    DEPART,
    /**科室已经指定, 科室内分配*/
    OFFICE,
    /**责任人已确定, 等待责任人派工，等负责人统筹计划和联络业务小组组队。
     * 流程环节控制有问题！ 还没有真实去做检验工作就允许编制报告啊，流程缺少一个控制环节。
     * 可直接在这里采用逻辑补位方案： 人工控制，责任人必须负责在已经真正检验启动了才能做责任人派工？？
     * 或者预派工通知人员工作量？或者在报告流转添加个前置0环节节点。或者是状态机ApprovalStm开启关闭BEGIN开关。
     * 【变数】可允许这个环节的且是自动生成任务单的：还能继续添加新的设备到本任务单。
     * */
    PERSON,
    /**已派工，检验时间最终确定，好了检验去，进入报告编制时段。
     * 已派工，@ 复检的(可重新指定人员)，重新派工，等待整改反馈复检报告
     * 底下的Isp若有需要复检的，针对要复检的部分设备要再次派工。
     * 复检派工可以细化到那个设备Isp底下的：特定Report某些子报告需要重新编制，# 但是主报告必须重新编制。
     * 派工时刻已经确认收费标准了，并选定报告模板(子报告/外包的子报告)；
     * =4；
     * */
    DISP,
    /**等待复检派工 (原班人马再去？)， Task底下的若有一个Isp需要复检，流转复检导致Task被迫进入 整改反馈期等待复检。
     * 挂起暂停;  监检的时间跨度周期很长的：也相当于算挂起吗｛有没有开动关闭按钮：暂停-继续：没意义｝。
     * 客户申请复检或责任人按照复检作业，可直接在旧Task重新派工。
     * 整改反馈期具体时间天数在报告下结论不合格需要复检或流转环节敲定。
     * 多个不合格Isp设备，反馈期取最大时间。
     * 过期处理: 拆分合格报告？ 不合格任务终结了，报告出具不合格报告，收费烂摊子? 预警监察超期未检验。
     * 等待整改反馈? TASK_STA=0.未派工；1.已派工；2.等待复检；3.等待整改反馈{实际上重新进入 DISP已派工 状态值}；4.已完成；5.作废；
     ！ HANGUP ??没必要；
     * 复检也是独立的Task吧, 若一个Task底下某一些Detail/Isp需要复检的？ 另外产生新的任务单task。
     没必要：2.等待复检；3.等待整改反馈？：两种情况：一种是小毛病的开具通知书让客户整改等着反馈之后继续后面的检验报告编制的下结论结束之前都能允许反悔。
     另外一种是：不能检验报告编制期间内无限期等待了，需要立刻给出不合格意见和完成报告编制阶段，可能需要新建立复检任务新Task来接续，旧的Task照旧走向结束路径。
     第一种情形，需要特意设立一个状态HANGUP。HANGUP设定一个30天的期限，等着对方驱动，若超期了：自动算为不合格吗？=强制终结任务吗/钱款已到账?=后续复检发起？。
     多个Isp/Detail中间某个设备Isp导致的任务状态不统一的？有些要继续等待，有些报告已发放了。钱款没有完全到账怎么人终结任务？需要审批步骤授权吧。
     * */
    HANGUP,
    /**已完成 任务已完成，发票已经开出，钱款已到账，报告证书已经发放，可能有不合格报告，证书不会不合格也打的；不合格的要复检的也得收钱到账吧。
     *前提是 Task底下的每一个Isp都已经终结了，
     *关联收费回款确保没有残余不可回收的风险。
     * 特殊情况比如长期协议合同或付款分期等的安排的事情需要看见关联事物的审批确认单，才允许终结任务。
     *CRDB数据库储存实际=6 数字int类型，但graphQL接口Task.status却是String型，前端直接是'DONE'；
     * */
    DONE,
    /**作废任务*/
    CANCEL;


    @JsonCreator
    public static TaskState_Enum fromName(String name) {
        return Arrays.stream(TaskState_Enum.values())
                .filter(type -> type.name().equals(name))
                .findFirst()
                .orElse(TaskState_Enum.INIT);
    }

}



/*
旧平台两个字段：
*   TB_TASK_MGE.TASK_ALLO_STA=0部门分配{未派工作废} 1科室分配{未派工作废} 2责任人派工{作废/未派工/已完成},@ 3分配派工完成{已完成}；
*   .TASK_STA=0.未派工；@ 1.已派工；2.等待复检；3.等待整改反馈；4.已完成；5.作废；
 */
